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Guía de seguridad de las API 
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Las API son lo que mueve el mundo de las aplicaciones 


A estas alturas, todos sabemos que las API, interfaces de programación de aplicaciones, mueven el mundo. 
Más precisamente, hacen que diferentes aplicaciones modernas se comuniquen entre ellas. Las aplicaciones 
móviles o web pueden acceder a un backend donde se almacenan y procesan los datos. Las API pueden ser 
públicas, que permiten la comunicación entre aplicaciones de diferentes empresas, o privadas, lo cual es 
común, donde varias aplicaciones internas se integran en función de los objetivos del negocio. 


¿El resultado? Aplicaciones, sitios web y aplicaciones para móviles más eficaces y equipadas, con mayor 
funcionalidad y datos más diversos. 


Por ejemplo, en lugar de crear desde cero servicios de pago propios, las empresas de transporte compartido 
pueden añadirlos a través de las API de empresas de pago. Otro ejemplo son los agregadores de búsqueda de 
vuelos. Para mostrarnos los horarios, precios, destinos y todo lo que hay que saber sobre un billete de avión, 
se conectan a las bases de datos de las aerolíneas a través de llamadas API para extraer los datos adecuados 
y mostrarlos en la página de resultados del agregador. 


La importancia de las API no ha dejado de crecer a medida que aumenta el número de empresas que por 
definición otorgan prioridad a las API. En algunos casos, incluso el producto de la empresa es, en sí mismo, 
una API con un modelo de negocios centrado en su uso. Por ejemplo, si una empresa que proporciona datos 
meteorológicos ha convertido su API en su producto, otras empresas que deseen información meteorológica 
pagarán una cuota mensual por el acceso a esta. En muchos otros casos, dado que se espera que una 
aplicación interactúe con otras, las API se diseñan en conjunto o incluso antes que el código que da la propia 
funcionalidad al producto, en lugar de incorporarlas al final del desarrollo. 


Las empresas dedican tiempo y esfuerzo a diseñar su estrategia de API teniendo en cuenta cómo expondrá 
los datos adecuados, por lo que es fundamental para los beneficios y los modelos de negocios. 


Sin embargo, es complicado crear API perfectas, pues al igual que en otros tipos de software, habrá 
vulnerabilidades que provocarán retos de seguridad, como se verá en este documento. 


De momento, nos quedamos con que las API están en todas partes y su impulso va a aumentar en los 
próximos años, por lo que deben contar con protección. Por ello, examinaremos los ataques a las API y 
varios aspectos de una estrategia de defensa integral cuando analicemos la seguridad de las API de las 
organizaciones. 


GUÍA DE SEGURIDAD DE LAS API 


El impulso de las API en cifras 


90 % 61 % 


del tráfico que se mueve a través aumento interanual 
de Cloudflare es tráfico de API del tráfico de API 


Programmable Web' señala que hay más de 24 000 API conocidas publicadas. No obstante, en realidad la 
mayoría de las API son privadas y enlazan aplicaciones internas. Se estima que existen millones de 

API privadas. 

Cuando decimos que las API están adquiriendo impulso, Cloudflare es testigo directo de su crecimiento. De 
acuerdo con los datos de Cloudflare Radar del primer semestre de 2021, aproximadamente la mitad del tráfico 
de la red de Cloudflare estaba ligado a las API. Es más, aumentó en un 61 % entre 2020 y 2021. 


Dado que son depositarias de datos importantes, empieza a evidenciarse que representan una gran superficie 
de ataque que debe protegerse. ¿Cómo lo sabemos? Se han producido importantes ataques contra las API en 
los últimos años. 


https: //www.programmableweb.com/apis/directory 
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Una superficie de ataque 
en expansión 


Sabemos que las API están en todas partes y son 
fundamentales para el éxito de los negocios modernos. 
Exponen la lógica de las aplicaciones y pueden compartir 
datos confidenciales con otras aplicaciones. 


Claro que, obviamente, los atacantes en ruta son conscientes 
de ello y albergan intenciones de explotar esta superficie de 
ataque en expansión en las empresas. 


Posiblemente, Gartner no se equivocaba al afirmar que, en 
2022, los ataques a las las API “pasarían de ser los vectores 
de ataque más aislados a ser los más comunes, provocando 
fugas de datos en las aplicaciones web de las empresas”. 


Aún está por ver si las API se convertirán en el principal 
vector de ataque, pero está claro que continuarán estando en 
el punto de mira de los atacantes en ruta. 


Decimos "continuarán" porque el mundo ya ha sido testigo de 
algunas fugas de datos de alto nivel debidas a una seguridad 
de API insuficiente o a un desarrollo API que no tuvo en 
cuenta la seguridad. 


T-Mobile fue víctima de un ataque de API en 2017 que 

dejó expuestos los datos de 15 millones de clientes, los 
cuales habían comprado nuevos dispositivos o solicitado 
cuentas de T-Mobile. Entre estos datos se incluían el 
nombre, la dirección, la fecha de nacimiento, el número de la 
seguridad social, el número de permiso de conducir y el de 
pasaporte. Vice informó que el ataque se realizó ajustando 
el parámetro del número de teléfono en la llamada API. Se 
podía consultar el número de teléfono de cualquier usuario 
y la API de T-Mobile enviaba respuestas que incluían datos 
confidenciales de la cuenta de la persona cuyo número 

se consultaba. 


Otra fuga de datos relacionada con la API fue la del Servicio 
Postal de los Estados Unidos (USPS), debida a que una 

API que daba soporte al seguimiento en tiempo real de los 
paquetes no contaba con un sistema básico de autorización. 
Cuando un usuario iniciaba sesión, podía consultar datos de 
cualquier otro usuario a través de parámetros de búsqueda 


“Fuente: Gartner: "API Security: What You Need to Do to Protect 
Your APIs", marzo de 2021 


con caracteres comodín que liberaban todos los registros 
del conjunto de datos. Se pusieron en riesgo los datos de 60 
millones de usuarios del servicio. 


En 2019, JustDial, un importante motor de búsqueda de India, 
filtró de hecho todos los datos de clientes al dejar expuestas 
versiones anteriores de las API que ya habían sido sustituidas 
por nuevas versiones. Es más, ni siquiera había un proceso 
de autenticación, por lo que cualquiera podía hacer llamadas 
API y extraer datos del servidor de producción. Dicho de 

otra manera, no se requería ninguna técnica avanzada para 
acceder a los datos de los usuarios. 


Facebook, a pesar de su liderazgo con GraphQL, también 
ha sufrido varias fugas de datos a través de sus API. Por 
ejemplo, a finales de 2019, la extracción de una base de 
datos puso en riesgo los nombres, números de teléfono e 
identificadores de más de 260 millones de usuarios. 


Hay una larga lista de organizaciones que han tenido 
problemas con la seguridad de sus API. Los motivos son 
diferentes. Primero, las vulnerabilidades subyacentes de las 
API debidas a un diseño poco seguro abren las puertas a 
los ataques. Es más, hasta ahora, las organizaciones no han 
tenido herramientas de seguridad con prioridad en las API. 
Quizás usaban herramientas de seguridad web como WAF o 
limitación de velocidad, pero estas estaban diseñandas para 
proteger las aplicaciones, no las API. Esto puede provocar 
problemas como falsos positivos y pone en evidencia la 
necesidad de diseñar estrategias de seguridad de las API 
para un tráfico en gran medida automatizado. 
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¡Actualización! Nueva versión de los 10 principales 
riesgos de OWASP contra la seguridad de las API 


10 principales riesgos 


1. 
Ze 
3: 
4. 
Es tranquilizador contar con la implicación de la Fundación 
OWASP, una organización centrada desde hace tiempo en 
mejorar la seguridad de las aplicaciones. El proyecto OWASP, 5 
conocido por su lista de los 10 principales riesgos contra la j 
seguridad de las aplicaciones web ha publicado ahora un 10 
principales riesgos de OWASP contra la seguridad de las API 
una lista con los principales riesgos y vulnerabilidades de la 
seguridad de las API. 6. 
En realidad, lo que ya nos preocupaba en relación a la 
seguridad de las aplicaciones también es válido para el 7. 
diseño y la seguridad de las API. 
Para empezar, cualquier organización que dé prioridad 8 
a las API, debe tener en cuenta ante todo la seguridad al i 
diseñarlas. Veamos algunos de los ataques que acabamos de 
mencionar y el riesgo de seguridad señalado por el OWASP 9. 
que explotaron. 
10. 


de OWASP contra la 
seguridad de las API 


Autorización de nivel de 
objeto vulnerable 


Autenticación del usuario interrumpida 
Exposición excesiva de datos 


Escasez de recursos y limitación 
de velocidad 


Autorización de nivel de función 
vulnerable 


Asignación masiva 

Mala configuración de seguridad 
Inyección 

Gestión inadecuada de activos 


Registro y seguimiento insuficientes. 
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Principales retos de seguridad de las API 


1. Autenticación y autorización vulnerables 


Para analizar más de cerca algunos de los principales riesgos de las API señalados por el OWASP, que fueron 
explotados en los ataques anteriores, empezaremos con la autenticación y la autorización. 


JustDial se vio afectado por la vulnerabilidad de la autenticación en sus puntos finales, que permitió que 
cualquiera accediera a ellos. Cuando se implementa la autenticación, solo pueden realizar solicitudes las 
llamadas API que cuenten con el certificado TLS adecuado, claves de API, tokens web, etc., lo que reduce 
drásticamente los riesgos de seguridad de las API. 


En línea con el número uno de la lista del proyecto OWASP, muchos ataques a las API explotan las 
autorizaciones poco seguras, vulnerables o inexistentes, como se vio con el USPS y con T-Mobile. Es común 
la vulnerabilidad de la autorización de nivel de objeto, cuando los puntos finales de la API se explotan 
sustituyendo el número de identificación (ID) de un objeto para el que se cuenta con autorización por otro 
cuyo acceso no está autorizado. Muchas veces, solo con cambiar el ID de objeto de una solicitud, se consigue 
acceso no autorizado a los datos. 


La ruta API y los parámetros de la consulta incluyen el ID del recurso al que se accede. 


Llamada autorizada: 


GET api.greatsampleapis.com/v1/users/235 donde 235 es el identificador de usuario. 


Las llamadas API manipuladas pueden conseguir acceso no autorizado cambiando 235 por 236, esto es, 
ajustando el ID de objeto, el de usuario en este caso, para acceder a los datos del usuario 236. 


GET api.greatsampleapis.com/vl/users/236 


Si no existen controles de autorización, esto puede funcionar. Los desarrolladores deben diseñar el punto de 
conexión de acuerdo con un modelo de riesgos que garantice que los ataques no puedan ajustar o modificar 
el valor de un ID de objeto para acceder a otros datos. El uso de valores de ID de objeto impredecibles puede 
contribuir a que no sean secuenciales y fáciles de adivinar. 
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2. Ataques de asignación masiva, exposición de datos e inyección 


Otras clases de ataques exponen demasiados datos en las respuestas o permiten que los objetos internos 
sean modificados con entradas. 


La exposición excesiva de los datos se produce cuando una API expone ampliamente propiedades de objetos 
y transmite demasiados datos como respuesta, dejando al cliente que realiza la solicitud la responsabilidad de 
filtrar los datos. 


Los atacantes en ruta pueden usar detalles adicionales de la respuesta para crear un ataque aún más 
poderoso o suplantar la identidad de correos electrónicos. Por ejemplo, puede usarse para crear correos 
convincentes de suplantación de datos una respuesta que proporcione todos los datos a continuación: 


£ 

uars 213 

“FirstName”:"Sanjay”, 

“LastName”:"Smythe”, 

“EmailAddress”:"ssmythethacketyhack.com”, 

“Occupation”: “Assistant to the Deputy Associate Vice Sub-undersecretary”, 
“DOB":"1986-05-21", 

“Bank":"Easygo Financial”, 

“AccountNumber”: 1362886306, 

“PetName”: “Aloysius”, 


} 


Los ataques de asignación masiva permiten que las llamadas API alteren o exploten valores internos cuando 
las API exponen objetos o variables internas. 


Desde el OWASP lo explican así: 


"En ocasiones los marcos de software permiten que los desarrolladores asocien automáticamente los 
parámetros de solicitudes HTTP a variables u objetos de código de programa con el fin de facilitarles su 
uso. Los atacantes en ruta a veces usan esta metodología para crear nuevos parámetros no previstos 
por el desarrollador, que luego crean o reescriben nuevas variables u objetos no previstos en el código 
del programa". 


¿Qué deben hacer los desarrolladores? Deben comprender los riesgos potenciales de las llamadas de 
asignación masiva en el desarrollo e impedir que se expongan objetos o variables internas que se puedan 
explotar.También pueden considerar la realización de listas de permitidos con las propiedades que los 
clientes pueden actualizar. 


Durante mucho tiempo, las aplicaciones web han sido vulnerables a los ataques de inyección. Lo mismo 
sucede con las API. Dado que los ataques de inyección son muy conocidos, no nos extenderemos más en 
ellos, pero baste decir que las entradas se deben validar y corregir antes de transmitirlas. Se debe trabajar la 
prevención de las fugas de datos en las respuestas de la API y limitar el número de registros que se pueden 
transmitir para prevenir incidentes de revelación masiva. 
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3. Abuso de recursos y API fraudulentas 


Otros ataques abusan de las API consumiendo cantidades excesivas de recursos de proceso, lo que las 
satura de manera similar a un ataque DoS. Estos ataques se facilitan si no existen límites en cuestiones como 
el número de solicitudes por cliente o recurso, los registros transmitidos en una sola respuesta o el tamaño de 
la carga útil de la solicitud. 


Como vimos en los ataques de JustDial, las API de producción olvidadas pueden convertirse en API 
fraudulentas, ya que se pueden explotar al quedar desprotegidas. Como es habitual en seguridad, debemos 
tener visibilidad sobre nuestras propiedades informáticas o superficies de ataque para aplicar controles de 
seguridad adecuados. La visibilidad sobre nuestros puntos finales de la API es similar. 


Al desarrollar las API, los equipos deben contar con un proceso meticuloso que haga seguimiento de las 
versiones para saber qué API está en producción y qué se ha quedado obsoleto. 


Consideraciones para proteger las API 


Hemos hablado de qué son las API, su importancia y los ataques que generalmente se dirigen contra ellas. 
Ahora examinaremos cómo Cloudflare ha diseñado su seguridad para protegerlas contra los ataques más 
comunes. Una estrategia de seguridad de las API efectiva debe tener todo en cuenta, desde la visibilidad a 
los modelos de seguridad positiva o la protección de datos bloqueando los abusos. 


Cloudflare API Shield 
DDoS de Visibilidad Autenticación Modelo de Detección Detección 
capa3 y 7 de API sólida seguridad de de datos 


positiva de API anomalías confidenciales 


Fundamentos de la visibilidad 


Visibilidad 
Como en otros aspectos de la seguridad, debemos ver algo para poder protegerlo. Las API no son diferentes, 
en especial cuando las empresas tienen cientos o incluso miles de puntos finales de API. 


La exhibición y la visibilidad de las API son un aspecto fundamental de su control, por lo que las 
organizaciones deben poder visualizar claramente los puntos finales de la API de su propiedad para prevenir 
los problemas con API fraudulentas. 


Como vimos con JustDial, si una organización no presta atención a sus API, se pueden producir fugas de 
datos. 
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Defensa sistemática de las API 


Protecciones de API de capa 7 


Desde hace tiempo, hemos implementado firewalls de aplicaciones web para proteger las aplicaciones contra 
los ataques DDOS a la capa 7. La protección de las API debe comenzar con muchos de esos controles fiables, 
como la limitación de velocidad y la protección contra DDoS, para impedir los ataques de denegación de 
servicios, los intentos de inicio de sesión por fuerza bruta y los abusos generales realizados por direcciones 
IP específicas. Así se aplicarán límites al uso de las API y se garantizará la disponibilidad, para combatir el 
cuarto ataque a las API según el OWASP: escasez de recursos y limitación de velocidad. 


Las reglas de WAF se deben usar también para identificar y bloquear ataques comunes dirigidos contra las 
API. 


Autenticación y autorización 
Autenticación MtLS 


Ya vimos en los ataques a API mencionados que la falta de autenticación puede ser demoledora. La 
autenticación debe estar integrada desde el comienzo y respaldada con TLS mutuo, para que se ejecute la 
identidad basada en certificados en casos como loT o móvil. Este es un enfoque más positivo de listas de 
permitidos que solo autoriza la conexión de solicitudes de clientes legítimos con certificados válidos. 


Comprobaciones de credenciales expuestas 


Las API no son inmunes a los ataques de relleno de credenciales, con ciclos de intentos de inicio de sesión 
con credenciales robadas. Las credenciales de las cuentas se pueden en riesgo en fugas de terceros, ajenas 
al control de la organización. Como parte de los controles de autenticación, la seguridad de la API debe poder 
comprobar en el inicio de sesión que las credenciales no se encuentran en una base de datos de credenciales 
robadas. Si se sospecha que están en riesgo, la seguridad API debe iniciar medidas adicionales, como el 
restablecimiento de contraseñas o la autenticación multifactor y, por supuesto, bloquear el ataque. 
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“parameter”: 5.7, 
“data” z} 


“data3” : 8 
) 


Llamada API © 
——— 


Escudo de API 
con protección 
de esquema 


“parameter”: 6 
“datar: { 
"datat" :7, 
"data2" : “hello” 


i 


Llamada API 


{ 
“parameter”: “integer”, 
“data”: ( 
"data1" : “integer”, 
"data2" : "string" 
y 
} 


Esquema de OpenAPI 


La validación de esquema evalúa las solicitudes en relación con un esquema de inicio de sesión o de bloqueo de solicitudes 
de API que no lo cumplan. 


Protección de API positiva 
Validación de esquema de API 


Los desarrolladores se han esforzado mucho para crear un esquema de API, que consiste en la 
documentación o reglas básicas para que otras personas interactúen con la API. Con ello pueden 
establecerse elementos tales como los métodos y operaciones de solicitud en cada punto final (GET /users, 
POST /users) o los parámetros de entrada y salida para cada operación. OpenAPI v3, también conocido como 
el estándar Swagger, es el esquema más conocido para definir las API. 


Una seguridad de las API fiable debe usar un modelo Zero Trust, que aplique un esquema. 


Cuando se ha establecido un esquema, las solicitudes se deben automáticamente mediante este. Todas las 
operaciones de API se bloquean, excepto aquellas que se hayan validado conforme al esquema. 
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